

\chapter{General Discussion}

This project looked at how memory introspection can be done, the internals of memory address translation, mapping the memory and implemented a prototype integrity monitor to detect changes to the static kernel objects specifically the system call table in the current version of the prototype.

There are changes in a Xen kernel that is different from a normal kernel. For example the Interrupt descriptor table is not available in virtualized host running on Xen. So it is not possible to detect the integrity of the static kernel table IDT. The integrity monitor design should identify these changes in the Xen enabled kernels.

Xen virtualization has introduced a third memory level in its memory management. Due to this the mapping of memory is done in individual memory frames at a time. When mapping memory for the integrity detector to use a memory frame containing the starting address is mapped. If a kernel object spans across multiple frames, additional work have to be done to align the raw memory as contiguous memory. This was found to be a additional thing that should be looked into when mapping memory regions.

The current version of the prototype integrity monitor successfully detects changes to any element of the system call table immediately and with a negligible performance penalty as the only a small area is being detected. The ability to detect system call table change can detect any rootkit that tries to change the system call table. Copilot paper describes some rootkits that change system call table. These rookits will surely be detected by the prototype detector.

The process list generation was attempted but finding the precise task\_list struct of the vulnerable VM was not a easy task to do. Therefore building up the process list was not possible. Without the precise data type of the structs are essential to build up the linked list that describe the processes running on the system. Considering task\_list struct the difficulty is not being able to determine the struct using the source code as it describes different internal data structures for task\_list for different kernel compilation configurations. This is the same difficulty faced when recreating the semantics of any kernel object.

Rootkits that can be run on the system were needed for the testing for the success of the integrity detector. There were no publicly available rootkits that run on 2.6 kernels other than the adore-ng-0.41 rootkit. Even adore rootkit did not compile on the 2.6.18 and 2.6.22 kernels. Modifying the available rootkits to run on a 2.6 kernel would have needed an extensive study into the rootkits. This caused the testing using a real rootkit impossible.

The findings of this project can also contribute to the implementation of honeypots based on Xen. The events that are been run on a VM will have to be captured to enable the logging of activities a honeypot does.

In real life situations even though it is hard to compromise a VMM, there are methods in which the VMM can be compromised. Attacks on Virtual Machine Emulators paper \cite{VMattacks} describes the types of attacks available to VMMs. Even though the attacks available for Xen is low, there is always some possibility of Xen been attacked. The possibility to avoid a attack on the VMM can be achieved by securing the Dom0 as much as possible.


Xen is a open source project with many contributors and actively moving forward in developments. The pace at which changes to the code happen cannot be caught up in documentation. Understanding the internals of Xen requires a substantial amount of low level operating system constructs. Therefore trying to change the source of Xen to obtain any service to run on Xen is not a feasible approach at a undergraduate level. Simply the understanding of the source code is impossible as the code has been written to optimize the performance.

When implementing a system on top of some other technology like Xen, you tend to freeze the version of the technology that you are using as a change management procedure. Therefore the latest developments of Xen are not possible to be explored. Specially because unlike other application level projects, Xen would be the base to the operating system that you work on. Upgrading would cause the higher level applications to be constantly changed which might not be possible. Therefore during the period of the project I had to constrain myself to the latest possible version available at that time and use that version throughout.



\chapter{Future Works}

The work to be done in this field of technology is a lot. Still there have not been commercially available intrusion detection systems that run on virtualization. This is a field of studies that has many work to be done in the future and the work that has been done have to be realized by others interested in the technology.

Next versions of this integrity monitor will require the integrity checking of other static kernel objects, the integrity checking of system calls and static kernel code. The ability to identify if a memory location holds data or instructions will also be useful.

When a change in kernel tables occur, the changed value can be restored to the original values. At the moment the memory is mapped in a read-only manner, but to restore kernel table entry values the memory will have to be mapped with write enabled. The impact this can have should be analyzed. Most probably there won't be an issue as writing is only enabled by the Dom0 and it's maintained in a secure manner.

Implementation of a successful integrity detector on Xen would require the ability to Map kernel objects and instruction code that span for multiple memory frames. Memory for the VMs don't see a contiguous abstraction of memory as the hypervisor handles that complexity and provides a contiguous looking physical memory for the VMs. When accessing memory through mapping that maps one frame at a time, this complexity will have to be handled by the application.  A approach that can hide the non-contiguous nature of virtualized memory and provide a contiguous abstraction should be implemented.

The next most important future work is to extract the data types using a kernel image and providing those data types to the integrity monitor to re-create objects. Semantic regeneration of memory is not only important for introspection but also for digital forensics. The most successful semantic generation that can be achieved is when at runtime be able to handle different kernels with changing data types. The integrity monitor should compiled independent of the kernel being monitored but when detecting a VM be able to extract the semantics of that kernel and map those objects correctly to the running integrity monitor.

%Integrity monitoring for the windows kernels that can run on Xen is also a work to be looked into.


\chapter{Conclusion}

In this thesis I have identified the importance for the need of intrusion detection systems based on  virtualization. The inability of commodity operating systems to isolate different parts of the kernel leads to the whole kernel getting compromised. Virtualization is the solution to the problem.

Using Xen it is possible to isolate the vulnerable kernel and the detection kernel making detection reliable. The memory mapping functionality of Xen provides the ability to look into the memory state of the vulnerable VM. 


There are many issues to address before a successful intrusion detection can be built. First the address of the needed kernel objects need to be translated, and then the required memory frames should be mapped and given a abstraction to be accessed as a contiguous block of memory. When the raw memory is obtained, the semantics of the kernel objects should be found and then the memory should be cast into the obtained data types. When the kernel objects are constructed there should be a way to dynamically change the created dynamic kernel object lists in a real time. After the underlying objects mimic the behavior of the vulnerable VM, there should be a developer friendly interface to access these kernel objects. Finally the intrusion detection logic can be implemented to do the necessary detection. The detection can monitor various parts of the kernel to detect for the proper functioning of the vulnerable VM. In case of a compromise the necessary action can be taken to correct the trusted operation again.

In this project the above mentioned steps were found to be needed when creating a intrusion detection system using virtualization. The prototype integrity monitor implemented in this project can successfully detect changes to the system call table in a real time manner and not affecting the performance of the system. The future versions of the prototype will include additional functionality described under future works.








